The present invention relates to systems and methods for providing add-on services to emails transferred via a distributed computer network. More particularly, the present invention relates to techniques for providing add-on services responsive to emails received at an email system, which techniques require little change to the email system itself.
Emails and email systems for providing computer users with email communication via a distributed computer network, such as the Internet, have been around for some time. In a typical Internet-based email system, a computer user typically employs an Internet-based email application program (e.g., Yahoo™ mail or another email front end that is accessible via a web browser) or a desktop-based email application program (e.g., Outlook™ by Microsoft Corp.), to compose an email. To direct the email to reach the intended recipient, the sender may provide a unique recipient email address, which typically includes the recipient's user name and a domain name. Together, the recipient's user name and the domain name comprise a unique email address.
Once the sender or a program (generically referred herein simply as the sender to simplify discussion) issues the command to send the composed email to the specified unique email address, the email message, with the unique recipient email address as its header, is sent via the distributed computer network, e.g., the Internet, to an email service provider that services the specified domain. Along the way, the email typically passes through a plurality of mail relay stations, using the store-and-forward paradigm. Once the email arrives at the email service provider that services the specified domain, the email system may notify the recipient that he has an email waiting to be retrieved, or the email system simply waits until the recipient logs in to check his email folder to inform him of the existence of a new email to be read.
To facilitate discussion, FIG. 1 illustrates a simplified representation of a typical email arrangement which allows email senders 102 and 104 to transmit emails to an email recipient 106. With reference to FIG. 1, email sender 102 may employ an email front end 108, which as mentioned earlier may either be a browser-based email application program or a desktop-based email application program that has a gateway to the Internet, to compose the desired email message and to specify the unique address of the email recipient. If the email system is HTTP-based (as in the case of front end 108A), a web-server 190 is typically employed to permit the email to be transferred in the SMTP format. If the email front-end employs the SMTP format (as in the case of front end 108B).
After the email is composed, email sender 102 may command email front end 108 to transmit the email to email recipient 106 by issuing a send command. When email front end 108 receives the send command, it forwards the composed email message, including the recipient email address as its header, to distributed computer network 110, which in this case is the Internet. Internet 110 is represented, as is conventional, by a cloud. Within this cloud that symbolically represents the Internet, the email system that provides email service for the domain specified in the email address resides. In the example of FIG. 1, such an email system is illustrated by an email system 130. Since email system 130 resides in the distributed computer network, the email message typically arrives at email system 130 through a plurality of connecting legs and relay facilities. To simplify the illustration, these relay facilities, which are distributed within Internet 110 between email front end 108 and email system 130, is illustrated by a relay cloud 132.
In the current art, emails relayed through the Internet also typically employ a suitable email protocol to allow the emails to be efficiently relayed to the appropriate destination. One such protocol is SMTP (Simple Mail Transfer Protocol). In the example of FIG. 1, the transmitted email is first received at email system 130 by an SMTP server 140. SMTP server 140 then ascertains whether the recipient is indeed one who is serviced by email system 130. Assuming that the email recipient is associated with a domain (e.g., “abc.com”) which is serviced by email system 130, SMTP server 140 then forwards the email message to a database facility 142, which stores the received email message in an appropriate mail box accessible by the intended recipient of the email message.
Thereafter, email recipient 106 may employ an appropriate email front end 150 to access Internet 110 and ascertain, via web server 152 of email system 130, whether there is an email message waiting for email recipient 106 within database facility 142. If there is, email recipient 106 may access the email message by sending a command via email front end 150 to email system 130 to request the email message to be sent from email system 130 to email front end 150 to be displayed thereon.
If email front end 150 is implemented in a web browser that displays HTML-formatted pages or a similar protocol, an HTML converter facility 158 or an appropriate protocol converter facility may be employed to convert the email message to an appropriate format prior to sending the email message to email front end 150 via web server 152. The arrangement of FIG. 1 is conventional and may include other implementational details and variations, which are well known to those in the business of providing email service and will not be discussed in great detail here for brevity's sake.
As Internet revenue models evolve, email service has become one of the loss leader services that many portals or web businesses are expected to provide. In other words, many users expect free email service from their portals as a condition for their patronage. As a result, many providers of email systems have been forced to turn to advertisement revenue to operate and maintain their email systems. FIG. 2 illustrates a simplified exemplary prior art technique for providing advertisement-based emails using the basic architecture of FIG. 1. In the example of FIG. 2, an advertisement insertion module 170 interfaces with HTML converter facility 158 to insert an appropriate advertisement banner into the email message prior to sending the email message to email front end 150. In this manner, the emails are received by the recipients with advertisements inserted by the email system. This arrangement results in payment from the advertisers to the email system operator, which provides a revenue base for the provider of email system 130 to operate and maintain the email system.
As the Internet evolves further, email users begin to demand even more sophisticated services from their email system providers. By way of example, many email users nowadays demand the ability to redirect their emails to other domains to allow all their emails to be centralized at one email system. Another service that many email users also desire nowadays is auto-reply, wherein the email system automatically notifies the sender with a preselected message (e.g., “I am away for two weeks,” “I got your message and I will get back in touch with you shortly,” or the like). Some email users may desire to receive their emails in the form of voice or facsimile while they are on the road and may accordingly require these capabilities from their email system. Other security-related services, such as anti-spamming services, virus-scanning services, are also popular on the list of desirable features among email users.
For many email system providers, these demands represent a significant challenge. For one, most email services are provided to email users free of charge, which makes it difficult for email system providers to find the necessary financial resources to update their email systems to provide such services. More significantly, given the speed at which products and services associated with the Internet evolves, many email systems may have been designed earlier without advance knowledge of future services and features that users may eventually demand. As such, many existing email systems may have been designed without the necessary scalability and/or flexibility to allow these additional features to be readily and efficiently integrated. Even if such integration is possible, the task of integrating the new features into the legacy email systems may take an unacceptably long period of time, which may result in a loss of users and negative economic consequences for the portal operator.
By way of example, integrating a new feature into an existing legacy email system may require the staff of the email system to design codes implementing the new feature, to integrate the new codes into the existing software architecture, and to test/debug the updated email system prior to roll out. This assumes, of course, that the staff of the email system has the necessary expertise to implement the new feature and is knowledgeable about their legacy email system, which is often not the case if the operator merely leases the codes from a third party software developer (in which case, the email service operator may not even have access to the source code). Of course the email service operator may always negotiate with the third party software developer to have additional features implemented. However, this is also time-consuming, and the result depends for the most part on the willingness and expertise of the third party software developer to implement the new desired features.
Still further, it is oftentimes the case that by the time the email system operator realizes the need for a new feature, such new feature may have already been implemented elsewhere by another third party developer. In the typical situation, users often are aware of the existence of a new feature from other sources first and push for their own email system operators to offer the same feature. In such cases, it may be more efficient for the email service provider to lease or license the already implemented codes instead of writing new codes. However, if the email service provider wishes to integrate the codes representing the desired features with the codes of the legacy email system, compatibility, scalability, testing, and debugging issues still require time to resolve. Unless email system providers can find a way to quickly and efficiently integrate the new services and features into their legacy email systems, as well as find a way to finance the new services and features, they may lose users and/or suffer serious financial consequences.
In view of the foregoing, there are desired improved techniques for providing new services and features to users of an existing email system in a way that requires little change to the existing email systems and at little cost.